In an application domain such as in medical care, tasks being performed in a hospital for example, are cross departmental and involve several people, each with a different role. These coordinated activities are typically referred to as “Workflow”, with an example being the processing that occurs as a patient moves through the hospital “system”. The first step is “admitting”, which may be followed by an examination and then detailed lab work and imaging. This is followed by a review of the information with recommendations for further tests, or treatment. There are various tools that operate in this enterprise—wide workflow. For example in the imaging part of this process there are specific software tools that are required for the imaging (scanner consoles), image review and the treatment system. Thus it is desirable that the software tools that operate in this enterprise-wide workflow may be simply integrated.
There is thus a need for a single application framework. This framework should define how components from different sources can be mixed to generate various coherent “applications”. This approach does not mean that the framework is a pre-requisite to the use of those components—it is desirable that the individual components can be used outside the framework (e.g., there will be simple applications that do not need the services of the framework, but they should still be able to use some of the components that are generated for this architecture).
It may be noted that in a given “application” may be defined by a main workflow, with sub workflow's within this main application, if one is concerned with both “complex applications”, and with applications that span multiple users (i.e., enterprise-wide work-flow). The aim here is to consider only a single “application”—a useful distinction is to consider that there is “workflow” within an application (which is to be supported by the framework), and there is also a “Workflow” at a higher level within, for example, the hospital.
Users in a particular workflow have to use components from different vendors, which have different interfaces or paradigms. Thus the user has to relearn new procedures resulting in errors and inefficiency. In a typical application the user is presented with a selector for data, and then a set of “protocols” or tasks that can be performed on that data. With the closer integration of enterprise-wide work-flow, this model should evolve so that the data and protocol may be specified externally (e.g., in a work-list).